1. Technical Field
The present invention relates in general to the data processing field. More specifically, the present invention relates to the field of Object Oriented programming techniques and mechanisms.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices. Modem computer systems contain relatively complex software that the computer hardware executes in order for the computer system to perform its intended functions. As the complexity of computer hardware and software increases, the need to efficiently and effectively develop new software becomes more acute. Software development costs have continued to rise because complex programs take more time, and hence more money, to produce. Object-oriented programming is one way computer programmers have sought to reduce the time and costs associated with developing complex software.
The goal of using object-oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with development. In addition, by creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Typically, object-oriented software programs or processes create and use objects to accomplish the required or desired goals of the application software. Most software processes will create an object or objects and then use those objects during the processing cycle for that particular process. Once the software process that created the object has completed its processing requirements, the objects associated with that process are removed from memory. This means that the objects created and used by one process are not typically accessible by subsequent processes because the objects have been destroyed.
It is sometimes desirable to have an object created by one program process available to other program processes, even after the process that created the object has ceased to run. This type of an object is known as a "persistent" object. A persistent object can be stored on a disk or other secondary memory storage device. Then, when the creating process is terminated, the persistent object remains in secondary storage and can be accessed by a subsequent process. By using a persistent object, a copy of an existing object can be stored and then retrieved at a later time and used to create a new object, after the original object is destroyed. While the new object is not technically the same object, the new object will have the same characteristics and attributes as the original object. The use of persistent objects permits certain types of information to be shared between disparate processes.
"Externalization" is the means or protocol used in object-oriented programming for transferring data into and out of an object, including persistent objects. The externalization process is accomplished using memory areas which are defined as "streams". Externalization procedures can be used to "stream" or transfer data from a streamable object to a memory location and thereby preserve the data and characteristics associated with the streamable object. This data can then be internalized at a later time into a new object and made available to other processes that may need to use the original streamable object. Streams are typically implemented using files or memory buffers as a memory area for storing object-related information from a streamable object.
While existing externalization protocols recognize persistent objects, current externalization procedures provide only limited support for creating and managing persistent objects and references. In the current implementation of externalization, in order for persistent objects to maintain references to other objects, all of the data and references associated with a given object must be stored in a single stream. For example, referring now to FIG. 3, one problem with the existing implementation of persistent objects is illustrated. In FIG. 3, object A is a persistent or streamable object which references objects C.sub.1 -C.sub.n. Object B is a non-streamable object which references object C.sub.j. In this case, if object A is externalized using a standard externalize command, all of the contents referenced by A (objects C.sub.1 -C.sub.n) must also be externalized into a single stream. When the process that created object A has run to completion, the original object A is destroyed or removed from memory. Then, when object B requires access to object C.sub.j, the entire contents of object A must be retrieved and internalized into a new object. While this procedure may be possible in certain instances, if the amount of data represented by objects C.sub.1 -C.sub.n is sufficiently large, then system memory constraints may become a limiting factor. This is particularly true if there are multiple objects (like object B) that each maintain independent references to multiple individual objects (like object C.sub.j) that are also referenced by object A. Even if the memory space is large enough to hold all of the information contained in C.sub.1 -C.sub.n, loading unnecessary information into memory is a highly inefficient use of limited computer resources.
Referring now to FIG. 4, another problem with current externalization procedures is illustrated with the concept of state data. The type of data that can be streamed from a streamable object during the externalization process typically includes "state data", which is the information regarding the characteristics of the object when the object's contents are externalized. For the purposes of this specification, the term "state data" will be broadly construed to include other object-related data. This would include object security access characteristics, pointers to other objects, etc. In FIG. 4, object A contains the state data for object A (SDA) and also contains a reference to object C which contains the state data for object C (SDC). Similarly, object B contains the state data for object B (SDB) and also contains a reference to object C. Object C "supports" persistent references. When object A is externalized, SDA and SDC are stored in stream A. Likewise, when object B is externalized, SDB and SDC are stored in stream B. Then, when a later process requires access to objects A and B, the data in stream A is internalized into a new object A and the data in stream B is internalized into a new object B. Since both streams recognize a reference to object C, two new and separate objects are created, each as object C. This is problematic for several reasons. First of all, the memory storage and allocation concerns are obvious. Twice as much memory is required for creating and storing two objects, both identified as object C. More troubling is the fact that object A and object B no longer reference the same object C. The original relationship between the three objects has been altered. Depending on the nature of the original relationship, the new objects may no longer function together as intended.
As the complexity of both computer hardware and software increases, the need for better ways of implementing persistent objects becomes more apparent and more acute. This is especially true as more and more computers are connected by networks such as the World Wide Web and share information across different computer systems. Without an improved mechanism for implementing persistent objects the computer industry will be hindered from taking full advantage of implementing and using persistent objects across different processes.